What is the problem this PR solves?

Currently any error returned back to Fleet Server from elasticsearch that is not 401 or 429 is returned as a 401 error. This tells the calling client that the API key is invalidate. That is only true when the error is 401, otherwise the error means something different.

How does this PR solve the problem?

This solves the issue by returning the actual error back elasticsearch to the calling client. This means that a 500 error from elasticsearch will not result in a 401 back to the client, instead it will be a 500 error.

This uses the standard es.ParseError logic to determine the error and return something readable to the calling client.

How to test this PR locally

• Bootstrap Fleet Server
• Turn-off elasticsearch
• See that 401 is not returned to the client

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• [ ] I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected. (no effect on scale)
• [ ] I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc. (no effect)

Checklist

• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

• Closes Return 503 Service Unavailable when unable to authenticate with Elasticsearch instead of 401 #3929

  ---

  This is an automatic backport of pull request Fix bad error handling in api key auth #3935 done by Mergify.